
APPN: Key in IBM’s 
Networking Blueprint 

On March 25,1992, IBM unveiled its networking blueprint for the 1990s and beyond 
and announced many products and statements of directions that build on that blue¬ 
print. The major networking elements of this announcement are shown in Table 1. 
SNA Perspective sees APPN as a key component in this blueprint and the centerpiece 
of these announcements. 

Because of the significance of this announcement and its APPN components, we are 
devoting the entire issue to it. In this first article, we review the major components of 
the announcement; discuss the significant implications of APPN and the networking 
blueprint for IBM; note several APPN issues including security, performance, and 
network management concerns; examine APPN past and future evolution; discuss 
APPN interoperability support and strategy—including IBM’s new networking 
blueprint and multiprotocol transport network (MPTN) direction; review old and new 
VTAM and NCP node Type 2.1/APPN support; discuss fourteen peer features and 
advantages of the new VT£M APPN support, including meshing of subarea and 
APPN network directories, elimination of PATH table definitions to add APPN 
nodes, and statements of direction for APPN border node and APPN session routing 
over channel connections; describe several APPN-supporting features to be offered in 
the future for NetView and note APPN support still required in NetView. 

(continued on page 2) 


APPN Insights and Design Clues 

APPN evolved from the need in the early 1980s to support the networking needs of 
what IBM then called small systems—primarily minicomputers and, increasingly, 
personal computers. Although originally termed an SNA extension, APPN today is 
properly called a networking architecture. 

This article provides our readers with a rare treatment of APPN. SNA users 
unfamiliar with APPN will get a good grounding. All readers will get insights into 
several aspects of APPN not widely understood inside or outside of IBM. These 
insights include design clues to reduce TDU flows, specifics of optimal route 
selection, and lucid descriptions of the four types of APPN searches. LEN node, 
APPN end node, and APPN network node are described. We discuss four APPN 
node services: configuration services, topology and routing services, directory 
services, and session services. 

(continued on page 14) 
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March's APPN Implications 

The announcement of VTAM APPN support in itself 
is quite significant However, considering it together 


with other announcements made on the same day, 
previous APPN developments, and interoperability 
implications with TCP/IP and OSI, SNA Perspective 
believes these signify that APPN is a key centerpiece 
architecture through the 1990s and beyond. The 
implications are far-reaching for several reasons: 


Networking Elements of IBM March 1992 Announcements 

Product/Programming Announcements 

Advanced Communication Function/Virtual Telecommunications Access Method (ACF/VTAM) 

Version 4, to be shipped for testing to selected customers by end of 1992. Date for general 
availability will depend on testing, but SNA Perspective expects it about the middle of 1993. 

VTAM APPN support: APPN end node and network node on VTAM V4 for MVS and SOD for VM. 
APPN network access through NCP, 3172, and channel (SOD) connections. 

Composite network node (CNN) based on APPN support in VTAM V4 and a future release of NCP. A 
VTAM node with APPN and its NCPs, if any, appear as one APPN node. Replaces composite LEN node. 

Networking Services/DOS (NS/DOS). Includes an 80K version of APPC and APPN end node. 

Limited dependent LU support over APPN in VTAM V4: will support LUs in nodes directly attached to 
their boundary function nodes. 

Statements of Direction* and Preannouncements 

Network Control Program (NCP) SOD. A future release will, with VTAM V4, support composite network 
node (CNN). Note: NCP will not contain APPN network node or end node; it will only participate in 
CNN. SNA Perspective expects announcement by September 1992. 

VTAM APPN border node SOD. Allows cross-network network node connections. 

APPN session routing over channel-to-channel support SOD. 

VTAM and 3174 SODs for dependent LU server/requester support across APPN. 

APPN support on AIX SNA Services/6000 SOD. APPN end node and network node and CPI-C. 

NetView SOD. A future release will support several features for APPN. An OS/2-based network 
management product in the NetView family will support APPN management. 

TCP/IP SOD. TCP/IP sockets support over SNA using LU 6.2 (SNAckets). 

CPI-C over TCP/IP work in progress. IBM working with a customer to develop prototype application. 

APPN on NetWare joint development. Strengthening of partnership with Novell to include APPN 
network node on NetWare. 

* Note: For IBM, a statement of direction used to always mean the product was at least two years away. 

Today, in many cases, the timeframe is much shorter, even as little as three months. 

Dates 

APPN on 6611 router. Availability date of first quarter 1993, given with full announcement details 
expected later this year. 

APPN network node licensing. Date given for licensing network node source code (2nd quarter 1992). 
Contents of and availability date provided for developer's kit (first quarter 1993). 

SAA Expansions 

Inclusion of APPN network node and TCP/IP in SAA CCS. ■ 
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• Pervasive. APPN is pervasive across, and 
unifies, IBM’s enterprise, departmental, and 
workstation platforms. 

• Strategic. APPN is a key strategic networking 
architecture to enable the computing paradigms 
of the 1990s and beyond. 

• Interoperable. APPN is well positioned to 
provide interoperability between Systems 
Application Architecture (SAA) and AIX 
systems for networked applications over SNA, 
TCP/IP, and OSI. 

Several issues are still outstanding, including 
performance impacts of dynamic networks, 
increased security concerns, limited NetView 
support of dynamic environments, concern about 
user response to phased release timeframe, limited 
3270 support, and constraints of VTAM APPN 
support being only in ESA. These are further 
discussed below under Issues and Implications. 

It should also be noted that, although we focus on 
APPN in this article and although IBM considers 
APPN strategic, the company also assigns a very 
high priority to supporting OSI, TCP/DP and other 
protocols which are included in the networking 
blueprint. 


APPN Continuing Evolution 

As Figure 1 indicates, APPN continues to evolve. 
The next level of APPN has been informally been 
called enhanced APPN or APPN+ by IBM. IBM 
has also discussed a further generation, which it has 
so far referred to informally as APPN++. In should 
be noted that, from the perspective of IBM’s 
networking blueprint, it is probable that the company 
will develop its high bandwidth support, including 
standards-based support for cell and packet routing, 
in such a way that all protocols, not just APPN, will 
be enabled by its implementation. 

APPN. The current level of APPN is now pervasive 
across the SAA and AIX platforms and provides 
peer networking throughout the host, midrange, and 
workstation environments. This level of support is 
provided in 1992 and 1993. 


APPN+. APPN+ will provide a fast packet 
capability in the 1993-1994 period. It is highly 
likely that APPN+ will also support standard 
interfaces such as frame relay. In addition to the 
general features in Figure 1, APPN+ will also 
probably include logical unit (LU) 6.2 transport for 
LU 2 and other dependent LU sessions, increased 
network management capabilities, and improved 
intermediate node routing. 

This fast packet capability will be part of a high 
performance routing (HPR) feature in APPN+. SNA 
Perspective believes that HPR will be based on a 
rapid transport protocol (RTP) that supports fast 
connection setup with data and which will be block, 
not byte, oriented. HPR will preserve all of the 
current SNA benefits of virtual route (VR) with 
priority provided through RTP. 

APPN++. APPN++ will be the transport basis for 
multigigabit connections and is planned for phase-in 
during the 1994-1995 period. APPN++ is likely to 
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be a standards-based fast packet set of routing 
protocols. APPN++ will probably include fast 
packet at multigigabit speeds, dynamic bandwidth 
management, support for all distributed computing 
models, and multimedia support. User applications 
requiring the very high bandwidth that will probably 
be supported by APPN++ include photorealistic 
image, freeze-frame video, full-motion video, high 
definition television, sonogram, 3-D medical images, 
scientific visualization, and compute-intensive, 
modeling-based business applications. 

APPN Is Platform-Pervasive 

APPN in VTAM has completed IBM’s strategic 
transition to support peer-to-peer networking across 
all primary SAA and AIX platforms. These 
products are shown in Table 2. 

APPN Is Key IBM Networking Architecture 
APPN is a key IBM networking architecture 
enabling the computing paradigms of the 1990s and 
beyond. Again, however, we note that IBM will also 
address these to significant degrees with OSI, 
TCP/IP, and other protocols/interfaces/environments 
as appropriate. These emerging paradigms include 
the following: 

• Client/server computing 

• Distributed transaction processing 

• Distributed database 

• Distributed file systems 

• Process-to-process communication 

• Single system image computing 

• Fast packet and multigigabit transport 

APPN Positioned to Provide Interoperability 

APPN’s pervasiveness across platforms, IBM’s 
transformation of SNA to a peer architecture, and 
IBM’s unified infrastructure foremerging computing 
paradigms are each significant achievements. 
However, these do not, in themselves, address the 
requirements of users with distributed, 
heterogeneous networks. 

End users and their applications cannot generally 
interconnect and share resources among dissimilar 


networks. Redundant network infrastructures within 
an organization have been a costly result of this 
situation. For example, between the same two 
locations, an SNA network may transport SNA data, 
a separate TCP/IP network transports TCP/IP data, 
and a further OSI network transports OSI data. 

User Needs in Heterogeneous Environments 

Seven user requirements in these increasingly 
unnavigable waters include: 

• Application support by function. Supporting 
applications based on their functions and not 
their underlying protocols. 


APPN Implementations 
in IBM SAA and AIX Platforms 

VTAM APPN support. Introduced in March 
1992 with Advanced Communication 
Function/Virtual Telecommunications Access 
Method (ACF/VTAM) Version 4 <V4) and - 
includes composite network node (CNN). 

AIX SNA Services/6000. Statement of 
direction (SOD) announced in March 1992. 

6611 router APPN network node. Statement 
of direction in January 1992. 

NS/DOS. Announced in March 1992 with APPN 
LEN node only. 

OS/2 Version 2 Communications Manager. 
Introduced in October 1991. 

Networking Services/2 (NS/2). Introduced in 
March 1991 to run with OS/2 EE Version 1.3. 

3174 APPN. Introduced as a microcode feature 
in March 1991. 

APPN for DPPX/370. Introduced for Distributed 
Processing Programming Executive/370 on the 
ES/9000 in September 1990. 

APPN for OS/400. Introduced as integral to 
OS/400 on the AS/400 in 1988. 

APPN for System/36. Introduced in June 1986. 

APPN (end node only) for System/38. 
Introduced in June 1986. ■ 
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• Application portability across platforms. 
Allowing these applications to ran anywhere on 
the networked or internetworked environments. 

• Transparent network infrastructure. Allowing 
applications to send and receive standard calls to 
and from a network interface so the selected 
network infrastructure is transparent to the 
application, end user, and application developer. 

• Resistance to obsolescence. Providing reliable, 
architecture-based solutions to incompatibility 
problems in order to transcend product life 
cycles and promote resistance to platform and 
operating environment obsolescence. 

• Network management Developing and managing 
heterogeneous networks as a single network. 

• Common adapters. Consolidating 
heterogeneous network protocols and traffic 
over common adapters, enabling reduction or 
elimination of redundant network resources. 

• Common transport. Providing common 
transport end-to-end across heterogeneous 
subnetworks. 

IBM Networking Blueprint 

In March, IBM unveiled two basic approaches to 
interoperability in its networking blueprint 

• Multiprotocol routing through the network 
across a backbone supporting multiple protocols 

• Multiprotocol gateways permitting transport of 
multiple protocols over a single backbone 
protocol 

IBM believes that a multiprotocol backbone 
provides the greatest flexibility in multivendor and 
multiprotocol networking topology. However, in 
some networks, a particular protocol may be 
preferred for the backbone, and this requirement can 
be addressed by the use of gateways using the 
common transport semantics function depicted in 
Figure 2. 

APPN and the Networking Blueprint 

SNA Perspective believes that APPN is important to 
either of these environments. In the first approach, 
by introducing peer networking throughout the SNA 


environment, SNA traffic will be able to be routed 
by network processors in the same way as other 
prevalent wide area network protocols. This is 
recognized by announcements of future support for 
APPN on several vendors’ multiprotocol routers in 
addition to IBM’s. However, if a gateway approach 
is preferred, APPN is a key protocol supported by 
the IBM direction to providing a multiprotocol 
transport network (MPTN) as shown in Figure 2. 

MPTN for Common Transport 

Figure 2 shows a model for MPTN with several 
possible APIs—including CPI-C (conversational, 
send/receive model), RPC (process-to-process, 
call/retum model), and message queueing interface 
(MQI; messaging model)—which provide interfaces 
into a wide range of upper-layer services. These, in 
turn, can be transported using APPN, TCP/IP, or OSI. 
In conjunction with MPTN, APPN is expected to 
increasingly provide the transport basis for TCP/IP 
and OSI applications as well as SNA applications. 

An MPTN is a collection of single protocol transport 
networks (SPTNs), each of which has its own 
transport protocol. These SPTNs may be inter¬ 
connected through groups of nodes with application- 
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specific gateways, such as IP routers in a TCP/IP 
network. MPTN will support logical, end-to-end 
connections as well as datagram services. End users 
and their applications will be unaware of the 
protocol or collection of protocols selected to 
transport their data across the network. The 
significance of this approach is that MPTN would be 
able to provide an any-to-any connection. 

One MPTN implementation would be a 
multiprotocol server rather than a gateway. For 
example, such a server could provide support for 
SNA, OSI, and TCP/IP and would interconnect 
client workstations that support, respectively, SNA, 
OSI, and TCP/IP. The actual MPTN routing 
function would likely maintain as unique the 
transport addresses used in each protocol group. 

An MPTN gateway could be used to connect 
multiple SPTNs to create an integrated 
heterogeneous network. One constraint of such a 
gateway is that it would probably be limited to the 
set of transport characteristics common to all 
participants (for example, normal data, no record 
boundaries, full-duplex connections). 

SNA Perspective believes that APPN, using the 
MPTN approach, will gradually become a transport 
mechanism of choice to interconnect heterogeneous 
distributed applications and their respective SPTNs. 
There are several reasons for this: 

• APPN provides a reliable and robust connection 
approach, more reliable and robust, in many 
opinions, than either TCP/IP or the ISO 
Transport Protocol Class 4. 

• APPN is evolving into a fast packet architecture, 
capable of supporting multigigabit speeds and 
dynamic, peer-to-peer networking with 
multimedia. 

• Sockets over SNA (SNAckets), which was 
discussed in a statement of direction in March 
1992, is a specific and significant example of 
APPN’s ability to provide underlying transport, 
in this case for TCP/IP socket addresses. SNA 
Perspective believes this is the first of many 
such multiprotocol routing capabilities to 
emerge using APPN. 


Prior Peer Networking 
in VTAM and NCP 

To establish a context for the VTAM APPN support 
announcement, it is useful to trace the evolution of 
peer networking in IBM hosts. 

VTAM V3R2, NCP V4R3/V5R2 

In June 1987, IBM introduced ACF/VTAM V3R2 
and ACF/NCP V4R3/V4R3.1 (3725) as well as 
ACF/NCP V5R1/V5R2/V5R2.1 (3745/3720). These 
included a host/NCP composite low entry 
networking (LEN) node. Specific VTAM V3R2 
features related to peer networking included: 

• VTAM APPC API. This introduced the LU 6.2 
Advanced Program-to-Program (APPC) API 
directly in ACF/VTAM. Its most important 
aspect was that host interprogram 
communications, which were previously 
restricted to Customer Information Control 
System (CICS) and to a less than elegant adapter 
for Information Management System (IMS), 
were made available to all application 
subsystems. [This benefit of this approach was 
shown in September 1990, when IBM 
introduced the SAA CPI-C interface into MVS, 
CICS, IMS, and TSO-E. All of these application 
subsystems, since then, support CPI-C calls to 
and from VTAM APPC and resident application 
transaction programs. Later, in 1991, APPC was 
added to Net View.) 

• Type 2.1 node support. Type 2.1 node support 
was the VTAM V3R2 basis for providing 
composite (subarea) node support for LEN node. 
This original host/communication controller 
peer networking feature introduced support for 
independent LUs as well as parallel sessions 
(both of which were supported only for LU 6.2). 
Nonhost LU 6.2 LUs could be defined as 
independent of the System Services Control 
Point (SSCP) and could therefore issue session 
BINDs to other host or nonhost LUs. With 
independent LUs, no SSCP-LU control session 
existed and a SSCP-PU control session was 
optional (e.g., needed for transport of network 
management data to Net View and support of 
downstream-attached dependent LUs). Parallel 
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sessions were supported between host and 
nonhost type 6.2 LUs, where multiple concurrent 
sessions and their corresponding conversations 
could be active between a single LU pair. 

• Dynamic table replacement. VTAM V3R2 
introduced a MODIFY TABLE command that 
allowed replacement of Unformatted System 
Service Table (USSTAB), Logon Mode Table 
(LOGMODE), Class of Service Table 
(COSTAB), and Interpret Table (INTERPRET) 
entries without having to halt or restart network 
VTAMs or NCPs. These table replacements can 
be performed globally or selectively. 

• Dynamic PATH table update. This enables 
subarea path changes to be rendered without 
inactivating or regenerating NCP and used 
VTAM library dynamic PATH update members. 

Dynamic Table Replacement (for USSTAB, 
LOGMODE, COSTAB, INTERPRET) and Dynamic 
PATH Table Update were not actually dynamic in 
the sense that table changes require discrete system 
definition and are not modified dynamically as a 
function of downstream configuration changes. 
However, they significantly improved system 
availability over prior versions, where subarea 
network table changes required at least partial 
disruption of data traffic to make changes. 

VTAM V3R3, NCP V5R3 

In October 1989, IBM introduced ACF/VTAM 
V3R3 and ACF/NCP V5R3. From the perspective 
of peer networking, two major functions were 
introduced in addition to the initial VTAM V3R2 
and NCP V4R3/V5R2 peer support: 

• Type 2.1 node boundary function support. 
Boundary function controls nonsubarea node 
access into a subarea network. For VM hosts. 
Type 2.1 nodes had more options for connecting 
to VTAM—via X.25, the ES/9370 
Telecommunications Subsystem Controller over 
SDLC leased/switched lines, and the ES/9370 
Token-Ring Subsystem. VTAM V3R2 and NCP 
V4R3/V5R2 only supported nonhost Type 2.1 
connections to the host through an NCP. 


• Casual connection. This feature enabled 
adjacent NCPs to interconnect as Type 2.1 nodes 
and allowed VM VTAM nodes to connect to 
either adjacent NCPs or VM VTAM nodes as 
Type 2.1 nodes. 

VTAM V3R4 , NCP V5R4 
In September 1990, IBM introduced ACF/VTAM 
V3R4 and ACF/NCP V5R3.1 and V5R4. From the 
perspective of peer networking, three major 
functions were introduced: 

• Type 2.1 node boundary function was added for 
MVS as had been introduced for VM VTAM 
with ACF/VTAM V3R3. MVS boundary 
function support was through 3172s. 

• Dynamic network access. VTAM V3R4 
eliminated, to a great extent, previous system 
generation requirements for devices attached 
through leased and switched lines. Type 2.1 
nodes could access a subarea network over 
multiple connection without prior LU 
predefinition to VTAM. This node Type 2.1 LU 
feature with VTAM V3R4 worked with the non¬ 
native network connection (NNNC) capability 
and, in so doing, removed many instances that 
previously required coordinated system 
definition across networks. 

• Multi-tail support. VTAM V3R4 also 
introduced support for dynamic switched 
definitions for both SSCP-dependent and SSCP- 
independent LUs and physical units (PUs). 
Reusable model definitions for dial-in PUs and 
dependent LUs were also introduced in concert 
with a configuration services installation exit 
routine. Multi-tail implies that, for APPC, any 
boundary function can be used for connection 
into a subarea with no definition required. 


VTAM APPN Support 

VTAM APPN support was introduced along with 
ACF/VTAM V4 in March. VTAM APPN support 
adds APPN network node and end node into 
traditional subarea environments. VTAM V4 was 
announced for MVS with a statement of direction 
presented on VTAM V4 for VM. 
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Composite Network Node 
IBM also stated that, at the time VTAM V4 ships, a 
then-current release of NCP will work with VTAM 
APPN support to provide a function called 
composite network node (CNN). CNN provides to 
the APPN network the appearance that a given 
VTAM APPN network node and all of its associated 
NCPs are one (composite) APPN network node. 

VTAM APPN Support With or Without NCP 

VTAM can be a standalone APPN network node 
(without NCPs) and can connect to APPN networks 
via an integrated channel adapter (ICA) or through 
the 3172. A VTAM APPN network node need not 
own NCPs; it is a configuration option. A VTAM 
APPN end node never includes NCPs, although it 
can attach to NCPs as part of a composite network 
node. An NCP can only be part of composite 
network node, never an APPN node by itself. 

APPN Network Node in SAA 

IBM also announced the inclusion of APPN network 
node into SAA Common Communications Support 
(CCS). APPN end node had already been added to 
SAA CCS in March 1991. ACF/VTAM V4 for 
MVS/ESA now provides a full implementation of 
CCS APPN end node and network node protocols. 

Features and Advantages 
of VTAM APPN Support 

There are many advantages to VTAM APPN 
support. Below, we list fourteen features and 
functions that we feel deserve mention and discuss 
several of them in detail. 

APIs. All APIs are fully supported, including CPI- 
C, APPC API, 3270 (SOD), RPC, and MQI, and 
existing operator and network management 
interfaces will continue to operate 

Subsystem and Operating System Impacts. There 
is no apparent impact on subsystems and their 
applications. This is significant because past VTAM 
enhancements have often required upgrades in 
application subsystem software levels in order to 
provide the full degree of promised improvement. 
However, on the operating system side, VTAM 
APPN support requires an ESA level of MVS and, 
when announced, VM. 


Dependent LUs. IBM announced support in limited 
configuration for dependent LUs (LU 0,1,2,3) 
across APPN in VTAM V4 and made a statement of 
direction to enhance this support in a future release. 
Support will be provided in VTAM V4 for a 
dependent LU in a 3174 or other node attached 
directly to its boundary function VTAM/NCP node, 
that is, over a single hop. The statement of direction 
discusses the mechanism to support a dependent LU 
supported by a node attached anywhere in the APPN 
network, that is, multiple hops away from its owning 
boundary function. 

The dependent LU support in VTAM V4 requires no 
changes to the connection between the LU and its 
boundary function node nor to its target application. 
The dependent LUs can also be existing dependent 
LU emulators such as 3270 gateways. It provides 
broad support for dependent LU features including 
SLU-initiated sessions, queuing session requests, 
autologon, third-party initiation, printer release 
request, etc. 

The statement of direction discusses two elements 
for dependent LU support: the dependent LU server 
(DLS), which will be implemented in VTAM, and 
the dependent LU requester (DLR), which can be a 
3174 or other node supporting dependent LUs. As 
the DLS, VTAM will provide the SSCP function for 
dependent LUs by communicating with DLRs. 
Products implementing the DLR function will have 
an LU 6.2 session upstream to the DLS in VTAM. 
The LU 6.2 pipe or control session will carry control 
flows for dependent LUs. The DLR will receive the 
control flows enveloped in an LU 6.2 session, open 
the envelope, and pass the traffic downstream. 

As an additional benefit, these dependent LUs need 
not be predefined in VTAM because the DLR owns 
the LUs as APPN resources and will register them to 
VTAM’s directory using APPN. 

This statement of direction indicates that APPN 
network node support added to the 3174 in March 
1991 may have been a sleeper announcement—this 
could provide a new lease on life for the beleaguered 
3174 (see “3174 Hard Hit by Gateways,” SNA 
Perspective February 1992) and is an early signal to 
competing vendors such as McDATA, IDEA 
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Courier, and Memorex/Telex of a requirement to 
support APPN. On the other hand, router and 
gateway products from vendors licensing APPN 
network node may still prove more popular with 
users than the 3174 option. 

The full dependent LU support over APPN, when 
available, will prove a boon for users with large 
installed bases of 3270 devices who wish to preserve 
their investment in 3270 applications and staff 
experience and yet have them participate in the 
relative freedom afforded by APPN dynamic 
networking. 

SNA Perspective believes that lack of dependent LU 
support to date has restrained many users in their 
decision to migrate to APPN. Because many users 
will continue to use most existing 3270 applications 
indefinitely, even over peer networks, we think 
IBM’s addition of this dependent LU requester/ 
server support as soon as possible is critical to the 
success of APPN. 

Meshing Subarea and APPN Directories. VTAM 
APPN support will transform APPN Locate flows to 
subarea cross-domain flows (CDINIT, DSRLST, 
etc.) or vice versa. Therefore, VTAM will provide 
seamless directory and session setup procedures 
across APPN and subarea networks including SNI. 

Central Directory Server. VTAM APPN support 
will provide a central directory server function for 
APPN networks. When a VTAM network node is 
configured as a central directory server, it will 
advertise this fact when it sends topology updates for 
the node; when other APPN network nodes 
recognize that a central directory server exists in the 
network, they will forward resource search requests 
to it unless the resource location is known. The 
central directory server will check whether the 
resource location is known to itself or to other 
central directory servers in the network before it 
resorts to a broadcast search mechanism to find the 
resource. When it leams the resource location, it 
will cache the information to satisfy subsequent 
requests. Thus, broadcast would be done only once 
for a target LU (rather than by each network node). 
VTAM normally has a larger database than other 
network nodes, so the resource caches would be kept 


longer. Also, VTAM will also store the database on 
the disk so that it can be reloaded during netwoik 
restart. To further avoid broadcast searches, a 
feature called central resource registration will have 
VTAM application LUs registered in central 
directory servers with their status (active/inactive). 

PATH Table Definitions Eliminated. The benefits 
of eliminating PATH table definitions to add a new 
VTAM APPN network node or end node are 
discussed in the sidebar on page 10. 

Migration From Subarea Addressing to APPN 
Addressing. Subarea networks use preassigned local 
and network addresses. Local addresses are used 
between a VTAM/NCP boundary function and a 
peripheral node (e.g., PU 2 and PU1). VTAM local 
and network addresses are assigned during major 
node activation and NCP local and network addresses 
are assigned at NCP generation. Also, these subarea 
addresses persist between sessions until changed by 
a manual system generation process. 

APPN networks, on the other hand, use local 
addresses for routing on a session-oriented basis. 
That is, APPN addresses are assigned at session 
activation and released at session termination. These 
temporary addresses are conveyed in a format 
identifier type 2 (FID2) transmission header as 
session identifiers. These sessions IDs, in turn, are 
associated with a specific session and with a specific 
transmission group between adjacent nodes. (A 
transmission group is currently equivalent to a single 
link in APPN.) Therefore, if an LU 6.2 session is 
established between LUs residing in nonadjacent 
APPN nodes, there would be two separate links 
involved for the end-to-end connection and two 
separate session IDs would be used for two separate 
session stages running over two separate single-link 
transmission groups. Each of these session IDs is 
called a local-fonn session identifier (LFSID). 
Further, an APPN network-wide identifier is 
established; this is called a fully qualified procedure 
correlation ID (FQPCID). 

VTAM APPN End Nodes Reduce Searches. 

When VTAM hosts are configured as end nodes, 
they will not be searched for unknown resources. 
These VTAM end nodes will register all LUs that 
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Benefits of Eliminating PATH Table Definitions 
to Add VTAM APPN Network Nodes 


Figure 3 provides a simple example of some of the 
PATH table entries that must be arbitrarily made in 
order to add a new VTAM subarea (VTAM 40 in Figure 3) 
to an existing host subarea SNA network. For the newly 
added VTAM subarea to support sending SNA data to 
the other three subareas, PATH statements have been 
made in VTAM 40 to arbitrarily define connections over 
transmission groups (TGs) in explicit routes (ERs) which 
are in turn part of virtual routes (VRs). 

In subarea SNA, a virtual route is logical, full-duplex 
association between a pair of endpoint subarea nodes 
which is defined to support an LU-LU session. Each 
virtual route further defines an underlying pair of 
reverse-direction explicit routes. Each explicit route is a 
simplex, physical path between the endpoint subareas 
defined within a virtual route. TGs, in turn, are logical, 
full-duplex connections between adjacent subarea 
nodes in one or more explicit route. 

Any addition, deletion, or modification of node or link 
resources in these subarea networks may require that 
all corresponding and interlocking table entries be 
changed accordingly. In large and complex SNA 
networks (Figure 3 shows a very simple network) these 
changes consume inordinate budget, time, and 
expertise, often across multiple data and cost centers. 


Figure 4 indicates that, if the same four hosts as shown 
in Figure 3 have VTAM APPN support, the need to 
configure PATH tables is now eliminated. This is an 
important feature of APPN network node which begins, 
for the first time, to provide the truly dynamic PATH 
table initially foreshadowed by VTAM V3R2. 

This is a simplified example because it does not include 
any NCPs, though it does demonstrate how operational 
costs may be reduced. In many cases with APPN, 
NCPs still require PATH definitions and PATH 
definitions among subarea nodes in a CNN are 
required. Existing PATH definitions need not be 
changed for already existing subarea routing networks. 

This feature is significant for several reasons: 

• PATH tables and their continuing maintenance are 
highly complex and error-prone in sizable subarea 
networks. Elimination of the need to manually 
generate and maintain PATH tables in VTAM APPN 
support is one of the most significant single IBM 
networking announcements in the past 10 years. 

• Many subarea networks, APPN networks, and 
subarea/APPN hybrid topologies are defined as 
single logical entities that encompass multiple data 
and cost centers. Subarea networks may also 
span multiple networks through SNA Network 
Interconnection (SNI) gateways. In all cases, any 
system definition changes (PATH changes 
especially) require close coordination between 
center managers and programmers. The virtual 
elimination of the need to coordinate PATH 

greatly 
cally reduce 
cost. ■ 
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can potentially be search targets to their netwoik 
node servers. Thus, data hosts need not perform 
netwoiking functions; they can focus their resources 
on application processing. Decreasing the number 
of netwoik nodes will also reduce overall network 
traffic for resource searches. 

Cascaded Searches. In subarea netwoiks, cross- 
domain session intiation requests (CDINITs) are not 
rerouted to other hosts, even if the CDINIT receiver 
knows that the target LU is located on an adjacent 
host Therefore, a host must search every host it is 
aware of individually for unknown resources. The 
APPN directory search mechanism allows search 
redirections, known as cascaded searches. In the 
case above, the receiver of a Locate request will 
reroute the request to all adjacent nodes. This 
reduces the number of CP-CP sessions required 
compared to the SSCP-SSCP sessions—a VTAM 
end node needs only a pair of CP-CP sessions with 
its network node server. 

Session Startup Cross-Domain Overhead 
Reduced to Two Flows. There are eight to ten 
cross-domain flows for a normal session setup and 
termination across SSCP-SSCP sessions, in addition 
to BIND and UNBIND flows. On CP-CP sessions, 
it can normally be reduced to two flows. To further 
reduce session setup overhead, VTAM may forgo 
sending Locate requests all the way to the 
destination if it knows the resource location and has 
the information for LU 6.2 session establishment 

APPN Uses Host’s Concurrent Processing. Since 
APPN components can take advantage of S/390 
multiple processors, Locate processing and session 
setup in VTAM APPN network nodes is faster and 
can reduce recovery time after a network failure. 

VTAM to Net View Data over CP-CP Sessions. As 
discussed later in this article under Network 
Management, network management data, with 
VTAM APPN support, can flow over CP-CP 
(APPN) sessions rather than SSCP-PU sessions as 
currently required. The CP-CP interface is expected 
to be more efficient for session traffic. 


Statement of Direction for VTAM APPN Border 
Node. A subset of border node was originally 
introduced with OS/400 V2R1 as Release 1 Border 
Node in April 1991. The architecture has been 
enhanced to implement it in VTAM V4. VTAM 
APPN border node functions will enable: 

• LUs in one APPN netwoik to establish sessions 
with LUs in another APPN netwoik 

• Search requests across netwoik boundaries 

• Isolation of network topology information 
between adjacent interconnected APPN netwoiks 

• Session problem determination flows across 
adjacent APPN netwoiks 

A VTAM APPN border node functions as a netwoik 
node in its native APPN network and also connects 
to an adjacent netwoik node in another APPN 
network. Two APPN networks are distinguished by 
their unique netwoik IDs. Previously, only LEN 
nodes, APPN end nodes, and composite LEN nodes 
could connect two APPN netwoiks because two 
netwoik nodes with dissimilar network IDs could 
not directly connect. The VTAM APPN border node 
will appear as a netwoik node in the non-native 
network topology database of another VTAM border 
node or a network node to which it is connected. 
VTAM APPN border node enables any number of 
APPN networks to interconnect and is designed to 
allow unlimited intermediate netwoiks to exist 
between the endpoint networks. 

Statement of Direction for APPN Session Routing 
over CTC. A future release of VTAM will provide 
support for APPN session routing over channel-to- 
channel (CTC) connections. 

Other March Networking 
Announcements 

Several network management announcements are 
discussed in the next section. Other related APPN 
and networking announcements in March 1992, in 
addition to VTAM APPN support and network 
management, include: 
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APPN on DOS 

Networking Services/DOS (NS/DOS) includes 
APPN LEN node and a much smaller version of 
APPC (about 80K) than APPC/PC. Because of the 
continued low market share of OS/2 compared to 
DOS and DOS-based systems like Windows, SNA 
Perspective sees this DOS support for APPN, even 
at the LEN node level, as an important concession 
on one hand (supporting other than its strategic 
workstation operating system) to increase market 
penetration of APPN on the other. 

Developing APPN on NetWare 

IBM and Novell announced joint development 
underway to include APPN network node on 
NetWare. SNA Perspective believes APPN on 
NetWare will provide a valuable market incentive 
for APPN migration. 

More; But Not All, APPN Licensing Details 

In March 1991, IBM announced that it would 
publish APPN end node protocols. In January 1992, 
the company stated its intent to license network node 
and in March, announced several details regarding 
the licensing of source code for APPN network node 
protocols. Licencing will begin in the second 
quarter of 1992 and the developer’s kit will ship in 
the first quarter of 1993. 

6611 Router APPN Date 

At the announcement of the 6611 router in January 
1992, IBM issued a statement of direction to add 
APPN network node capabilities. In March, the 
company provided an availability date of first 
quarter 1993. IBM has still not made a full 
announcement, including pricing and configurations, 
of APPN for the 6611. We expect its formal 
announcement in or before September 1992. 

TCP/IP Interoperability 
TCP over SNA. Capability for TCP sockets 
applications to communicate with each other over an 
SNA network using underlying LU 6.2 sessions was 
announced. SNA Perspective likes its internal 
working name: SNAckets. We like the concept 
even better and the example it provides of 
interoperability options to come from IBM. 


CPI-C over TCP/IP. IBM stated that CPI-C would 
support TCP/IP transport as well as SNA and OSI. 
The company is working with a customer to prototype 
an application to support this. Not quite far enough 
along to rate a statement of direction, but SNA 
Perspective has been recommending this move for 
some time (see “IBM’s Leading Communication 
APIs Face Off,” SNA Perspective March 1992). 

TCP/IP in SAA. IBM announced the inclusion of 
TCP/IP in SAA CCS. Although there is much 
industry debate over the importance of SAA as such, 
SNA Perspective believes that the inclusion of TCP/EP 
in SAA is at least symbolic of its strategic importance 
to IBM and further signals IBM’s commitment to 
interoperability within its networking bluprint. 

RS/6000: APPN and CPI-C 

IBM made a statement of direction to add APPN end 
node and network node as well as a CPI-C interface 
to AIX SNA Services/6000. Ihis is a further 
integration of SAA and AIX. 


Network Management 

Management services components had been defined 
in the APPN architecture that are essentially the 
same as those defined for subarea networks. 

Because APPN network management is not yet as 
thorough as for subareas, some features are not 
supported in APPN such as Response Time Monitor. 
See the January 1992 and February 1992 issues of 
SNA Perspective for an analysis of IBM network 
management for subarea and peer networks. 

In March 1992, IBM made a statement of direction 
to enhance support of APPN network management. 
This will be through APPN network management 
features which provide integration of APPN 
topology and APPC accounting data. These 
functions will include: 

• Dynamic collection and display of APPN 
network topology 

• Existing remote operator control applies to 
VTAM APPN resources 

• Collection facility for APPC accounting data 
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This additional NetView APPN support will work 
with a future release of NetView and with future 
capabilities of OS/2 V2 and Communications 
Manager. Tb provide these functions, IBM will add 
topology and accounting manager functions in 
NetView and alert focal points and topology and 
accounting agents in Communications Manager. 

The accounting data collection function is a 
welcome addition, as it will enable collection of 
APPC accounting data for sessions and conversa¬ 
tions and write these data to Systems Management 
Facility (SMF) records which, in turn, will assist 
network cost center managers in the arduous task of 
allocating network resource costs on a usage basis. 
However, it appears that some of the features 
discussed will require operator intervention or 
redundant efforts. 

APPN network management enhancements must 
keep pace with APPN enhancements. Otherwise, 
users can install networks that they cannot 
effectively manage. SNA Perspective believes that 
IBM has significantly enhanced APPN with the 
March announcements but NetView APPN support, 
both current support and this preannounced 
functionality discussed in March, does not yet have 
commensurate functional capability. Nonetheless, 
these NetView APPN features will represent a 
positive step toward providing dynamic network 
management for APPN environments. 


Issues and Implications 

SNA Perspective believes VTAM APPN support and 
the related announcements of March 1992 represent 
the most significant networking announcements 
from IBM in the past ten years, since the 
introduction of LU 6.2 under CICS in 1982. In 
addition to the APPN focus, IBM commitment to 
support for multiple protocols, interfaces, and 
environments was reiterated in the company’s new 
networking blueprint. 

The implications of the APPN announcements are 
far-reaching for several reasons: 

• APPN is now pervasive across enterprise, 
departmental, and workstation platfonns. 


• APPN is a key IBM networking architecture to 
enable the computing paradigms of the 1990s 
and into the next millenium. 

• APPN will increasingly provide interoperability 
for SNA, TCP/IP, and OSI networked 
applications. This will be based on IBM’s 
networking blueprint and its MPTN direction. 

Outstanding Issues 

Several outstanding issues remain to be resolved, 
including: 

• Performance bottlenecks. VTAM and NCP 
tend to create bottlenecks thus impeding 
performance in congested subarea networks. 
This tendency may be exacerbated in dynamic 
APPN networks where there are no predefined 
PATH and class of service table entries. 
Enhanced intermediate node routing is not 
expected until APPN+ in 1994 and dynamic 
bandwidth support is not expected until at least 
1995 with APPN++, so these performance 
considerations are likely to remain in these next 
few critical years of APPN market penetration. 
Several suggestions for more efficient user 
APPN network design are provided in the 
second article in this issue. 

• Security concerns in dynamic networks. 
Security is an ever-present issue in all networks. 
The notion of introducing dynamism into 
mission-critical network resources increases the 
possibility of unwelcome application access and 
tampering. It is critical for network designers 
and management to ensure that protective 
measures such as userlD, encryption, 
applicationID validation, end user authorization, 
and XID validation are enforced. 

• Focal point must become host independent. 
Products for all the major network management 
disciplines must be tested by significant IBM 
users and iteratively enhanced for dynamic, 
peer-to-peer networks in a middle-out approach 
to design—featuring user involvement at all 
stages of major product design, development, 
and testing. The preannounced NetView 
offerings for APPN support are a step in the 
right direction. Truly dynamic APPN awareness 
and expert systems logic must be incorporated 
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into Net View and all APPN network nodes as 
soon as possible. That is, the actual focal point 
intelligence and function must become host- 
independent. This is a challenge because it is 
concurrently critical to centralize network 
management data collection. 

• Timeframe of phased releases. 

SNA Perspective applauds IBM’s efforts to 
reveal its long-range APPN strategy to assist 
users in planning. However, in the face of 
TCP/IP’s blossoming popularity and its ongoing 
technical enhancements through the standards 
process, APPN has a short window to make a 
name for itself in the market and a long cycle of 
enhancements to include what users have been 
requesting for years. 

• ESA APPN constraints. VTAM APPN support 
will require ESA operating system levels. This 
means that users with previous iterations, such 
as XA or SP, will need to migrate to ESA before 
they can take advantage of these APPN features, 
which, in user’s eyes, significantly increases the 
total cost of APPN migration. 

• Support for Dependent LUs. Limited support 
for dependent LUs has restrained and will 
continue to restrain many users’ decision to 
migrate to APPN. Most existing 3270 applica¬ 
tions will continue to be used indefinitely, even 
over peer networks. IBM must fulfill its 
dependent LU requester/server statement of 
direction in APPN as soon as possible. 


Conclusions 

Taken together, these announcements are 
revolutionary for IBM networking. Many 
challenges remain, but we see APPN being 
positioned squarely as IBM’s pivotal networking 
integration architecture through the 1990s and 
beyond. IBM is also reponding to user input by 
strenthening its commitment to support TCP/IP and 
other protocols, which was expressed in this 
announcement through the IBM networking 
blueprint. 

by Thomas J. Routt ■ 


(continued from page 1) 


LEN Node 

All APPN nodes are based on IBM’s node Type 2.1. 
LEN node is the least functional of the node T2.1 
expressions. LEN provides for a basic, peer-to-peer 
connection between a pair of adjacent Type 2.1 
nodes over one or more links. There can be no 
intermediate nodes between the two LEN nodes that 
contain the LUs to be in session. LEN nodes 
provide the minimum functions required to make a 
connection between the adjacent nodes, establish a 
session between adjacent LUs, and transport data. 

LEN node has been implemented in VTAM/NCP, 
AS/400 OS/400, System/36 SSP, System/38 CPF, 
System/88 OS, Series/1 EDX V6 orRPS V7.1, 
RS/6000 AIX V3, RT PC AIX V2.2, PS/2 OS/2 EE, 
and PC with NS/DOS or APPC/PC under DOS. 

LEN connections can be established over SDLC, 
token ring, X.25, and Ethernet. 

APPN End Node 
and Network Node 

APPN end node is similar to LEN node in that an 
APPN end node can only directly connect to another 
APPN node if the two are adjacent. It can, however, 
connect to multiple network nodes, with one 
functioning as its network node server. Further, 
APPN end nodes do not provide services for other 
nodes such as directory services or routing. 

In contrast to LEN node, APPN end node contains a 
Control Point (CP) that enables communication over 
CP-CP sessions with an adjacent network node. 
From there, the LU in an APPN end node can 
communicate with LUs in remote, nonadjacent 
APPN end nodes or network nodes because the 
APPN network node contains an intermediate 
routing function. 

Connecting APPN Networks 

Prior to the 1993 delivery of VTAM APPN support 
and composite network node (CNN) described in the 
first article in this issue, it is already possible to 
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interconnect subarea and APPN networks. These 
connections can be made either as a pair of APPN 
networks connecting through a transit subarea 
network configured as a composite LEN node or as a 
pair of subarea networks connecting through an 
APPN network. A primary limitation, however, is 
that while LU 6.2-LU 6.2 sessions can be established 
across these dissimilar networks, they cannot 
establish CP-CP or SSCP-SSCP control sessions 
across the dissimilar networks. This is because, 
prior to VTAM APPN support, VTAM and NCP 
only support a composite LEN node function. 

APPN network node supports peer communication 
between nonadjacent Type 2.1 nodes and provides 
distributed, dynamic directories to enable LUs in 
nonadjacent Type 2.1 nodes to gain access to each 
other. APPN network nodes also provide adaptive 
routing functions since optimum routes are 
calculated as a function of previously specified class 
of service (COS) definitions. 

Major APPN Components 

Figure 5 shows the major components of APPN 
network nodes and end nodes. The APPN 
architecture is designed to interwoik with LU 6.2 
APPC. Therefore, APPN CP-CP control sessions 


APPN Node Components 



Figure 5 


are bound as LU 6.2 sessions. Both APPN and 
APPC are predicated on enabling networked 
applications in distributed control environments. 

Figure 5 distinguishes three major APPN node 
components: Node Operator Facility (NOF), 
Network Accessible Unit (NAU), and path control 
network (path control and data link control layers). 

Node Operator Facility 

NOF provides an interface between the node 
operator and CP components which, for example, 
allow the node operator to activate and deactivate 
link stations, define/delete LUs, query CP regarding 
status of links and other node resources, and receive 
diagnostic data. Node operators can be either human 
operators, command files, or transaction programs. 

Network Accessible Unit 

LU, intermediate session routing, and CP shown in 
Figure 5 are APPN NAUs. (Depending on context, 
intermediate session routing can also be considered 
part of path control.) The NAU set of APPN node 
components is based architecturally on the upper 
layers of SNA: transaction services (layer 7), 
presentation services (layer 6), data flow control 
(layer 5), and transmission control (layer 4). 

The LU behaves as a logical port into the network 
and can be defined as either SSCP-independent or 
SSCP-dependent. The intermediate session routing 
(1SR) NAU provides a session connector manager 
and a session connector. The CP NAU is made up of 
three elements: configuration services, session 
services, and address space manager (ASM). 

APPN Node Services 

APPN node services include configuration services, 
topology and routing services, directory services, 
session services, and network management. 


Configuration Services 

The configuration services component of an APPN 
node CP manages all local node resources including 
links to adjacent nodes. Specifically, CP 
configuration services is responsible for node 
configuration definition including types of data link 
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control, ports, adjacent link stations, attached 
connection networks, adjacent nodes, and link 
activation, nonactivation, and deactivation. 

Figure 6 illustrates a possible configuration services 
sequence in which an APPN network node (NN1) is 
added to an existing APPN network consisting of 
three network nodes (NN2, NN3, and NN4). 


Link activation and subsequent CP-CP control 
session setup proceed in phases. The connect phase 
is optional depending on the link—APPN supports 
SDLC switched, SDLC dedicated, token-ring 16/4 
Mbps, X.25 switched virtual circuit, and X.25 
permanent virtual circuit. In Figure 6, 
the connect phase consists of dialing, answering, and 
modem equalization. 


The assumptions for the example in Figure 6 include: 

• NN1 is defined with a separate link/TG to each 
of NN2, NN3, and NN4. 

• Each link is defined as switched SDLC with 
Modulo-8 frame sequencing. 

• Network node CPI (NNCP1) separately 
negotiates link station roles with NNCP2, 
NNCP3, and NNCP4. 

• In each negotiation, NNCP1 becomes the 
primary link station and therefore controls the 
link by sending SDLC commands and receiving 
SDLC responses. 


Configuration Services: Link Activation 
and CP-CP Session Activation 



(7) Connect phase 
(?) Pre-negotiation XID exchange 
(5) Negotiation XIO exchange 
(7) Data link control activation 
( 5 ) CP-CP session activation 


The prenegotiation exchange identification (XID) 
phase is also optional. If used, it begins with XID 
polling. APPN supports the use of a null XID poll 
to determine if the adjacent link station is active. An 
active adjacent link station responds to a null XID 
poll by sending a Format 3 XID (XID3) with an 
exchange state indicator (ESI) set to 
“prenegotiation.” An APPN link station can be 
configured as either primary, secondary, or 
negotiable link station. 

The negotiation XID exchange phase is used to 
determine which link station will become primary 
and which will become secondary. This is useful 
because negotiation of link station role significantly 
reduces time-consuming system definitions of 
adjacent nodes. In this phase, the XID3 ESI is set to 
“negotiation proceeding.” In this phase, node 
properties communicated to adjacent nodes include: 

• Adjacent link station (ALS) name 

• CP capabilities (network node or end node 
providing link services) 

• CP name 

• Link characteristics 

• Subarea PU name (if appropriate) 

• Product set ID 

• Node capabilities (parallel link/TG support, data 
link control support) 

The actual link station role negotiation proceeds 
through comparison of a 32-bit field call nodelD 
which is comprised of a product-specific block 
number and an ID number unique in the APPN 
network. 


Figure 6 
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Topology and Routing Services 

Topology and routing services (TRS) is a component 
of the APPN node CP. Its purposes are: create and 
maintain a topology database (topology database 
manager), select optimal route (route selection 
services), and maintain the class of service database 
(COS manager). 

Actual computation of the optimal path is conducted 
by route selection services (RSS), which generates a 
route selection control vector (RSCV) containing the 
best route through the APPN network to support a 
specific LU-LU session. RSS-calculated inputs to 
this process include data stored in multiple internal 
and external databases which, in turn, are managed 
by other TRS subcomponents. Upon TRS 
initialization, NOF passes these node parameters: 

• Node type (network node or end node) 

• Node CP name 

• Node network ID 

• Class of Service/Transmission Priority Field 
(COS/TPF) option 

• COS database file name 

• Topology database file name 

Optimal Route Calculation 

TRS calculates the best route by comparing the 
actual node and TG characteristics against the 
required route. In this process, qualitative node and 
TG characteristics are converted into quantitative 
node and TG weights. Actual and required node and 
TG characteristics are stored in topology and COS 
databases, respectively. TG characteristics include: 

• Link speed. The range is from less than 
4.8Kbit/sec to greater than 2Mbit/sec. 

• Cost per connect time. Not used for dedicated 
SDLC, token ring, or X.25 pennanent virtual 
circuit. 

• Cost per byte. Not used for dedicated SDLC, 
token ring, or X.25 permanent virtual circuit. 

• Security class. Seven levels ranging from 
nonsecure to Tempest level. 


• Propagation delay. LAN least; satellite greatest 

• Three user-defined fields. 

TRS topology and COS databases maintain node and 
mode characteristics. Node characteristics include: 

• Route addition resistance (RAR). The propensity 
of an intermediate node to function as one. 

• Virtual routing node (VRN). Not an actual 
routing node; used by end node 

• Congested 

• End node routing resources depleted 

• Network node routing resources depleted 

• Intermediate routing service supported 

• Border node functions supported 

Mode characteristics include: 

• Mode description name 

• COS 

• Maximum number of sessions 

• Maximum number of conversations 

• Locally controlled sessions 

• Pre-established sessions 

• Inbound/outbound pacing: fixed or adaptive 

• Maximum length of RU for sessions 

Once a CP-CP session has been activated between 
network nodes, a conversation is established 
between the network node topology database 
managers (TDMs) in adjacent network nodes. 

(CP-CP sessions can only be defined either between 
a pair of network nodes or between a network node 
and an end node.) 

Figure 7 (see page 18) provides an overview of the 
mechanism whereby topology data are exchanged 
between APPN network nodes. Each network node 
TDM creates and broadcasts topology database 
updates (TDUs) about the node itself and all locally- 
owned TGs to other network nodes. TDUs are 
carried in LU 6.2-architected General Data Stream 
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(GDS) records in GDS variable X’ 12C2’. TDUs 
convey node characteristics, TG ID, and data link 
control signaling data. 

Figure 7 shows NNCP1 in the process of joining the 
APPN network. The figure depicts TDU exchange 
in network node TDM conversations, which are 
allocated in the CP-CP control sessions established 
at the close of the sequence shown in Figure 6. 
Before a network node joins an APPN network, its 
local copy of the topology database contains only its 
local resources. Upon connection to the adjacent 
network nodes (NNCP2, NNCP3, and NNCP4 in 
Figure 7), it receives a copy of the current topology 
database and also generates a self-descriptive TDU 
which is then broadcast throughout the network. 

TDUs are exchanged whenever a network node local 
topology database is updated. Updates can be 
triggered by changes in node or TG characteristics or 
by activation, deletion, or restoration of links to 
adjacent nodes. 

Design to Minimize TDU Data Flows 

A major design consideration here—especially in the 
case of the incorporation of sizable VTAM/NCP 


resources into an APPN network—is how to 
minimize the data flows for TDUs. There are 
'several mechanisms to deal with this potential 
performance problem: 

• Design the APPN network with a small number 
of network nodes. End nodes do not maintain or 
exchange topology data. One design approach 
would be to define the majority of APPN nodes 
as end nodes which access the resources of 
relatively few network nodes. 

• Define several network nodes but designate a 
subset of these as topology and directory 
servers. (Note that IBM has not discussed the 
concept of topology servers, but SNA 
Perspective believes it would be an efficient 
approach.) This would dramatically reduce 
TDU flows. 

• Define several virtual routing nodes (VRNs). 

TG updates are not broadcast if the TG to a 
network node is activated or deactivated across a 
VRN. Therefore, VRNs can be used across LANs 
or X.25 to reduce system definition and TDUs. 

Several APPN features already limit TDU 
propagation: 


Topology and Routing Services 


NNCP 1 


NNCP 2 
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Figure 7 


• Network nodes propagate TDUs 
to adjacent network nodes. 
However, a network node does 
not retransmit a given TDU 
back to the network node from 
which it received the TDU. 

• Each node and TG in a network 
topology database is assigned a 
unique resource sequence 
number (RSN). RSNsare 
incremented to the next even 
value whenever the owning 
network node creates a TDU for 
that resource. The RSN enables 
a network node that receives a 
TDU to detennine whether the 
network node has or has not 
received that update earlier. 

This is the little-known 
mechanism for termination of 
broadcast TDUs. 
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• Flow reduction sequence numbers (FRSNs) 
prevent retransmission of large topology 
databases following temporary link outages. 
Records are maintained at each network node of 
what data have been previously sent to each 
adjacent network node. If a link fails between 
network nodes. FRSNs are exchanged over the 
link on reactivation of CP-CP sessions and, thus, 
only new information is exchanged. 


Directory Services 

Network nodes define a local directory database to 
maintain awareness of network resources and their 
location. Directory services maps network resource 
names to the CP names of their network node 
locations. Known resources may either be located in 
local nodes, adjacent nodes, or nonadjacent nodes. 

Directory Entries 

From the perspective of a network node, all end 
nodes and their resources are incorporated in a 
directory. Directory entries can be system-defined, 
registered, or cached. 

System-defined directory entries. APPN network 
resources may be defined by system-defined 
directory entries. These are created by node 
operators. (Refer to Figure 5 for an illustration of 
the relationship between node operators and the 
node.) Once a resource is locally entered, the 
network node server distributed search facilities can 
be used to locate it. 

Registered directory entries. These are temporary 
entries in the local directory database of an APPN 
network node. Registered directory entries represent 
the local LUs of an APPN end node for which an 
adjacent APPN network node acts as a network node 
server. 

Cached directory entries. These are resource 
locations retained by network nodes as a result of 
requests such as resource Locate requests. Two 
significant risks in caching are that it may result in 
unwieldy local database entry sizes and may include 
resource entries which are no longer current. A 
network node deletes cached entries for the end node 


resources for which it provides network node 
services upon deactivation of network node-to-end 
node CP-CP sessions. 

Searches 

A logical concatenation of multiple network node 
directories occurs when CP-CP sessions are 
established between them. This generates a “virtual” 
or distributed directory database. In this case, each 
network node can first search for a resource in its 
local directory and, if not found, can use the “locate 
search request” to search the directory databases of 
all other network nodes in an APPN network 

Many users are under the mistaken impression that 
APPN nodes must always use a broadcast search to 
locate LUs in nonadjacent nodes. If that were true, 
the impact of such overhead on network perform¬ 
ance would indeed be enormous. Although 
overhead in a dynamic APPN network can be higher 
that in a statically defined, traditional SNA network 
it is not as bad as that. Actually, four types of 
resource searches are supported: 

• LEN node locate search 

• APPN end node locate search 

• Broadcast search 

• Directed search 

LEN node locate search. Since LEN nodes do not 
support CP-CP sessions either between themselves 
or with an APPN network node, LEN node searches 
are restricted to a local directory database. 

APPN end node locate search. This search request 
is in the form “Locate_Message.” It initiates a local 
APPN end node directory search for the named 
resource. If the search is unsuccessful, the APPN 
end node directory services generates a “locate 
search request” which is forwarded to its network 
node server. If the network node server succeeds in 
locating the requested resource, it returns a “locate 
search reply” to the APPN end node. 

Broadcast search. If, in the previous case, the 
network node server is unsuccessful is locating a 
resource requested by an APPN end node, directory 
services at the network node server forwards the 
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“locate search request” to all adjacent network 
nodes. This is known as a broadcast search. Any 
downstream network node receiving this broadcast 
search request will further propagate it to all its 
downstream network nodes. It will not reply until it 
has received either a positive locate reply or negative 
responses from all the local nodes it serves. 

Directed search. If a broadcast search is successful, 
the network node server that initiated that search 
locally caches the locations of the LUs involved in 
the sessions. Any future request for a session 
between that same LU pair results in a positive find 
in that server. That server then constructs a route 
selection control vector (RSCV) containing all the 
session path information and presents it back to the 
requesting node. The requesting node then sends a 
directed search request to verify the location of the 
destination LU. If the taiget LU is no longer at the 
cached destination, a negative result to the directed 
search request is returned and the requesting 
network node server initiates a broadcast search. 

APPN searching can also be made more efficient by 
use of central directory servers. These are discussed 
in the first article under the section describing 
VTAM APPN support. 


Session Services 

APPN session services are responsible for CP-CP 
sessions, LU-LU sessions, and for the generation of 
fully qualified procedure correlation identifiers 
(FQPCIDs) and local-form session identifiers 
(LFSIDs). Session services coordinate with 
configuration services and keep configuration 
services up to date with regard to sessions. 

The session connector manager (SCM) interfaces 
with the LU session services component as well as 
the CP address space manager (ASM) to set up all 
the details necessary to construct an LU-LU session. 
To construct a session, SCM would: 


• Negotiate the maximum request/response unit 
(RU) size allowed for the intermediate node 

• Negotiate the type of session pacing and 
corresponding window sizes 

• Construct a session connector instance with a 
corresponding FQPCID for the end-to-end, LU- 
to-LU session 

• Calculate an LFSID used by the session on the 
incoming TG from the downstream node 

• Calculate an LFSID to be used by the session on 
the outgoing TG to the upstream node 


Network Management 

APPN network management components, issues, 
and concerns, were discussed in depth in the 
February issue of SNA Perspective. Aspects and 
issues of the March 1992 announcements are 
discussed in the first article in this issue. 


Conciusions 

We reviewed APPN’s predecessor LEN function and 
its current structure-as APPN end node and network 
node. We discussed components and functions of 
APPN node services. We provided several network 
design suggestions to improve performance by 
reducing TDU flows. We presented the specifics of 
how APPN selects optimal routes, which can assist 
the user in specifying appropriate route require¬ 
ments. We clearly described the four types of APPN 
searches, so that the user can configure APPN nodes 
to take advantage of search efficiencies. The reader 
is now more familiar with APPN than most SNA 
users or even IBM staff and is also armed with 
practical suggestions for planning or enhancing an 
integrated SNA and APPN environment. 

by Thomas J. Routt ■ 
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